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Overview of Systems Analysis and Design 

What is System? 

A system is a collection of components (subsystems) that work together to realize some 
objective. For example, the library system contains librarians, books, and periodicals as 
components to provide knowledge for its members. 



System environment 


Fig: Basic System Model 

Every system has three activities or functions. These activities are input, processing and 

output. 

• Input: It involves capturing and assembling elements that enter the system to be 
processed. Inputs to the system are anything to be captured by the system from its 
environment. For example, raw materials. 

• Processing: It involves transformation processes that convert input to output. For 
example, a manufacturing process. 

• Output: It involves transferring elements that have been produced by a 
transformation process to their ultimate destinations. Outputs are the things produced 
by the system and sent into its environment. For example, finished products. 

The system also includes other two additional activities. These activities include feedback 

and control. 

• Feedback: It is data about the performance of a system. It is the idea of monitoring 
the current system output and comparing it to the system goal. Any variation from the 
goal are then fed back in to the system and used to adjust it to ensure that it meets its 
goal. For example, data about sales performance is feedback to a sales manager. 

• Control: It involves monitoring and evaluating feedback to determine whether a 
system is moving toward the achievement of its goals. The control function then 
makes necessary adjustments to a system’s input and processing components to 
ensure that it produces proper output. For example, a sales manager exercises control 


Downloaded from: http://www.bsccsit.com 



























Systems Analysis & Design 


Page 2 


Chapter 1 


when reassigning salespersons to new sales territories after evaluating feedback about 
their sales performance. 

Theoretical approaches to systems have introduced many generalized principles. Goal 
setting is one such principle. It defines exactly what the system is supposed to do. There 
are principles concerned with system structure and behavior. System boundary is one 
such a principle. This defines the components that make up the system. Anything outside 
the system boundary is known as system environment. A system can be made up of any 
number of subsystems. Each subsystem carries out part of the system function i.e. part of 
the system goal. The subsystems communicate by passing messages between themselves. 

Several systems may share the same environment. Some of these systems may be 
connected to one another by means of a shared boundary, or interface. A system that 
interacts with other systems in its environment is called open system. Finally, a system 
that has the ability to change itself or environment in order to survive is called an 
adaptive system. 


What is an Information System? 

In a simplest sense, a system that provides information to people in an organization is 
called information system (IS). 

Information systems in organizations capture and manage data to produce useful 
information that supports an organization and its employees, customers, suppliers and 
partners. So, many organizations consider information system to be the essential one. 

Information systems produce information by using data about significant people, 
places, and things from within the organization and/or from the external environment to 
make decisions, control operations, analyze problems, and create new products or 
services. Information is the data shaped into a meaningful form. Data, on the other 
hand, are the collection of raw facts representing events occurring in organizations or the 
environment before they have been organized and arranged into a form that people can 
understand and use. 

The three activities to produce information in an information system are input, 
processing, and output. Input captures or collects row data from within the organization 
or from its external environment for processing. Processing converts these row data into 
the meaningful information. Output transfers this information to the people who will use 
it or to the activities for which it will be used. Information systems also require feedback, 
which is used to monitor the current information system output and compare it to the 
system goal. 

The two types of information systems are formal and informal. Formal information 
systems are based on accepted and fixed definitions of data and procedures for collecting, 
storing, processing, disseminating, and using these data with predefined rules. Informal 
information systems, in contrast, relay on unstated rules. 

Formal information systems can be manual as well as computer based. Manual 
information systems use paper-and-pencil technology. In contrast, computer-based 
information systems (CBIS) relay on computer hardware and software for processing 
and disseminating information. 
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Types of Information Systems 

In practice there are several classes of information systems in organizations. Each class 
serves the needs of different types of users. These are transaction processing system 
(TPS), management information system (MIS), decision support system (DSS), executive 
information system (EIS), expert system, communication and collaboration system, and 
office automation system. 

Transaction Processing Systems (TPSs) 

These are the computerized systems that perform and records the daily routine 
transactions necessary to conduct business. These systems serve the operational level of 
the organization. Some examples include sales order entry, hotel reservation systems, 
payroll, employee record keeping, and shipping. 

Transaction processing systems are central to a business. TPS failure for a few hours 
can cause a firm’s demise and perhaps other firms linked to it. Managers need TPS to 
monitor the status of internal operations and the firm’s relations with external 
environment. TPS are also major producers of information for the other types of systems. 

Online transaction processing systems (OLTPS) is an interactive data processing 
system that involves a direct connection between TPS programs and users. As soon as a 
single transaction is entered into a computer system, the program interacts immediately 
with the user for that transaction. It is often known as the live system where there is no 
time lag between data creation and its processing. A good example of this system is 
online ticket reservation system. 

Management Information Systems (MISs) 

These are the information systems at the management level of an organization and serve 
management-level functions like planning, controlling, and decision-making. These 
systems provide reports that are usually generated on a predetermined schedule and 
appear in prearranged format. Typically, these systems use internal data provided by the 
transaction processing systems. These systems are used for structured decision-making 
and in some cases for semi-structured decision making as well. Salary analysis and sales 
reporting are the examples in which MIS can be used. 

Decision Support Systems (DSSs) 

These systems also serve at the management level of the organization. These systems 
combine data and sophisticated analytical models or data analysis tools to support semi- 
structured and unstructured decision-making. These systems use internal information 
from TPS and MIS, and often information from external sources, such as current stock 
prices or product prices of competitors. DSS have more analytical power than other 
systems. Contract cost analysis is an example in which DSS can be used. 

Executive Information Systems (EISs) 

These systems are also called executive support systems (ESSs) and serve the strategic 
level of the organization. These systems are designed to address unstructured decision 
making through advanced graphics and communication. These systems incorporate data 
about external events such as new tax laws or competitors, but they also draw 
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summarized information from internal MIS and DSS. 

These systems are not designed to solve a specific problem but they provide a 
generalized computing and telecommunication capacity that can be applied to a changing 
array of problems. 5-year operating plan is an example in which EIS can be used. 

Expert Systems 

An expert system is an extension of DSS that captures and reproduces the knowledge and 
expertise of an expert problem solver or decision maker and then simulates the “thinking” 
or “actions” of that expert. These systems imitate the logic and reasoning of the experts 
within their respective fields. 

Expert systems are implemented with artificial intelligence (AI) technology that 
captures, stores, and provides access to the reasoning of the experts. 

Communication and Collaboration Systems 

These systems enable more effective communications between workers, partners, 
customers and suppliers to enhance their ability to collaborate. These systems use 
network technology that allows companies to coordinate with other organizations across 
great distances. These systems create new efficiencies and new relationships between an 
organization, its customers and suppliers, and business partners redefining organizational 
boundaries. 

Office Automation Systems 

Office automation (OA) is more than word processing and spreadsheet applications. 
Office automation systems support the wide range of business office activities for 
improved work flow and communication between workers, regardless of whether or not 
those workers are located in the same office. 

Office automation functions include word processing, spreadsheet applications, 
electronic mails, work group computing, fax processing, work flow management etc. 

Office automation systems can be designed to support both individuals and work 
groups. Personnel information systems are those designed to meet the needs of a single 
user. They are designed to boost an individual’s productivity. Work group information 
systems, on the other hand, are designed to meet the needs of a work group. They are 
designed to boost the group’s productivity. 

Systems Analysis and Design 

System analysis and design is a complex, challenging, and simulating organizational 
process that a team of business and systems professionals uses to develop and maintain 
computer-based information systems. It is an organizational improvement process. 
Information systems are built and rebuilt for organizational benefits. 

An important (but not the only) result of system analysis and design is application 
software i.e. software designed to support organizational functions or processes such as 
inventory management, payroll, or mark-sheet analysis. In addition to application 
software, the total information system includes the hardware and systems software on 
which the application software runs, documentation and training materials, the specific 
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job roles associated with the overall system, controls and the people who use the software 
along with their work methods. 

In systems analysis and design, we use various methodologies, techniques and tools 
that have been developed, tested, and widely used over the years to assist people during 
system analysis and design. 

Methodologies are comprehensive, multistep approaches to systems development that 
will guide your work and influence the quality of your final product: the information 
system. Methodologies use a standard set of steps. A methodology adopted by an 
organization will be consistent with its general management style. Most methodologies 
incorporate several development techniques. 

Techniques are particular processes that will help to ensure that your work is well 
thought-out, complete, and comprehensible to other on the project team. Techniques also 
provide support for a wide range of tasks like conducting interviews, planning and 
managing the activities in a system development project, diagramming the system’s 
logic, and designing the reports that the system will generate. 

Tools are typically computer programs that make it easy to use and benefit from the 
techniques and to faithfully follow the guidelines of the overall development 
methodology. 

To be effective, both techniques and tools must be consistent with an organizations 
system development methodology. These make easy for system developers to conduct the 
steps in methodology. 

Importance of Systems Analysis and Design 

Systems analysis and design is the collection of important activities that takes place when 
new information systems are being built or existing ones are changed. All the activities 
are needed to build good information systems. The systems developed by using systems 
analysis and design activities fulfill the requirements of organizations’ personnel. 

Furthermore, we can develop information systems easily and rapidly because there 
are lots of supporting methodologies, tools, and techniques. The information system can 
be built in the most effective way. The systems also fit into an existing environment and 
will be very easy to use and maintain. By following the activities involved in systems 
analysis and design, we can develop high quality information system within allocated 
budget and time. 


Information System Stakeholders 

A stakeholder is any person who has an interest in an existing or proposed information 
system. She/he may be technical or non-technical and internal or external worker. 
Stakeholders are also called information workers. An information worker involves in 
creating, collecting, processing, distributing and using information. 

There are six groups of stakeholders and each group has a different role in the same 
information system. But in practice, any individual person may play more than one role. 
For example, a system analyst may also work as a system designer. The six groups are: 
system owners, system users, system designers, system builders, system analysts and 
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project managers, and information technology vendors and consultants. 

System owners 

System owners are the information system’s sponsors and chief advocates. They are 
usually responsible for funding the project of development, operate, and maintain the 
information system. They are interested with-how much will the system cost? And how 
much value or what benefit will the system return to the business? 

Every information system has one or more system owners. They usually come from 
the ranks of managers to supervisors. 

System Users 

These are the people who use or are affected by the information system on a regular 
basis. They are concerned with the system’s functionality related with their jobs and the 
system’s ease of learning and use. A system user may capture, validate, enter, respond, 
store and exchange data and information. System users are also called clients. To know 
business requirements, discussions with most users need to be kept. 

System Designers 

These are technology specialists who translate system users’ business requirements and 
constraints into technical solutions. These are interested in information technology 
choices and the design of systems within the constraints of the chosen technology. They 
design the computer database, inputs, outputs, screens, networks, and programs that will 
meet the system users’ requirements. These designs guide the construction of the final 
system. 

System Builders 

These are also technology specialists who construct information systems and components 
based on the design specifications generated by the system designer. 

Systems Analysts and Project Managers 

A. Systems Analyst: Although, many people in organizations are responsible for 
systems analysis and design, in most organizations the systems analyst has the 
primary responsibility. The primary role of a systems analyst is to study the problems 
and needs of an organization in order to determine how people, methods and 
information technology can best be combined to bring about improvements in the 
organization. System analysts identify and validate problems and needs and ensure 
that the technical solution fulfills these problems and needs. 

Systems analysts study the system and identify and validate its problems and 
needs for system owners and users and ensure that the technical solution fulfills the 
business needs. 

B. Project Manager: To build a good information system and applications all the 
stakeholders must work together as a team. Teams require leadership. For this reason, 
usually one or more of these stakeholders takes on the role of project manager to 
ensure that systems are developed on time, within budget and acceptable quality. So, 
project manager is responsible for planning, monitoring, and controlling projects with 
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respect to schedule, budget, deliverables, customer satisfaction, technical standards 
and system quality. 

Information Technology Vendors and Consultants 

Most information systems are dependent on information technology that must be 

selected, installed and customized, integrated into business, and technically supported. 

This technology is developed, sold, and supported by IT vendors. 

Similarly, many businesses rely on external consultants to help them develop or 

acquire information systems and technology. The use of consultants may be driven by the 

need for specialized knowledge or skills or by an immediate need to complete a project. 

Preparing Career as a Systems Analyst 

System analysts are the key individuals in the information system development process. 

To succeed as a system analyst, you will need to develop the following skills. 

• Working Knowledge of Information Technology: This is the technical skill. The 
analyst must be aware of both existing and emerging information technology. Such 
knowledge can be acquired by college courses, seminars and training programs. 

• Computer Programming Experience and Expertise: This is also a technical skill 
needed by systems analysts. Most system analyst need to be proficient in one or more 
high level programming language. 

• General Knowledge of Business Processes and Terminology: Most of the systems 
today are business related and the systems analysts must be able to communicate with 
business experts to gain understanding of their problems and needs. So, this skill is 
must. To develop this skill, the system analyst should have knowledge about the 
courses like accounting, finance, business law and ethics, economics, manufacturing, 
marketing, operations management, human resource management, organizational 
behavior etc. 

• General Problem Solving Skill: The systems analyst must be able to take a large 
business problem, break down that problem into its component parts, analyze the 
various aspects of the problem, and then assemble into an improved system to solve 
the problem. To develop this skill, a system analyst should have knowledge about 
critical thinking and reasoning. 

• Good Interpersonal Communication Skill: To know the user requirements, an 
analyst must be able to communicate orally and in writing. To develop this skill, the 
courses like business and technical writing, business and technical speaking, 
interviewing and listening will be effective. 

• Good Interpersonal Relations Skill: The systems analysts should interact with all 
the stakeholders in the information system development project. To do this they must 
have this skill. To improve this skill, the analyst should have knowledge about the 
courses like teamwork, principles of persuasion, managing change and conflict, and 
leadership. 

• Flexibility and Adaptability: No two projects are alike. So, a successful system 
analyst must learn to be flexible and to adapt to unique challenges and situations. 
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• Character and Ethics: The system analyst should have strong character and a sense 
of right and wrong. This is needed to hide the sensitive and confidential facts and 
information of an organization. 

• System Analysis and Design Skill: All systems analysts should know concepts and 
principles, tools, and techniques of information systems development. 

Developing Information Systems and System 
Development Life Cycle (SDLC) 

Most organizations use a standard set of steps, called a systems development 
methodology to develop and support their information systems. It is a standard process 
followed in an organization to conduct all the steps necessary to analyze, design, 
implement, and maintain information systems. And systems development life cycle 
(SDLC) is the traditional methodology used to develop, maintain, and replace 
information systems. It includes different phases as shown in the figure below. This 
representation of SDLC is sometimes referred to as the waterfall model or classic life 
cycle. 


Planning > 


Maintenance 

Analysis 

\ / 

Implementation ^ 

Design 



Fig: The systems development life cycle 


The first phase is called planning. In this phase, someone identifies the need for a new or 
enhanced system. These needs are then analyzed, prioritized and arranged into a plan for 
the IS department. Here, a potential information systems project is explained and an 
argument for continuing or not continuing with the project is presented; a detailed plan is 
also developed for conducting the remaining phases or the SDLC for the proposed 
system. 

The next phase is called analysis. During this phase, the analyst studies the current 
system and proposes alternative replacement systems. Here, the analyst thoroughly 
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studies the organization’s current procedures and the information systems used to 
perform organizational tasks. The analyst work with users to determine what the users 
want from a proposed system. The analyst carefully studies any current systems, manual 
and computerized, that might be replaced or enhanced as part of this project. The analyst 
studies the requirements and structures them according to their interrelationships and 
eliminates any redundancies; generates alternative initial designs to match the 
requirements; compare these alternatives to determine which best meets the requirements 
within the cost, labor, and technical levels the organization is willing to commit to the 
development process. The output of this phase is a description of the recommended 
alternative solution. Once the recommendation is accepted by owners, you can begin to 
make plans to acquire any hardware and system software necessary to build or operate 
the system as proposed. 

The next phase is called design. During this phase, you convert the description of 
the recommended alternative solution into logical and then physical system specification. 
Here, you must design all aspects of the system form input and output screens to reports, 
databases, and computer processes. Logical design is the part of the design process that 
is independent of any specific hardware or software platform. Theoretically, the system 
could be implemented on any hardware and systems software. Physical design is the part 
of the design phase in which the logical specifications of the system form logical design 
are transformed into technology-specific details from which all programming and system 
construction can be accomplished. 

The next phase is called implementation. In this phase, the information system is 
coded, tested, installed, and supported in the organization. During coding, programmers 
write the programs that make up the information system. During testing, programmers 
and analysts test individual programs and the entire system in order to find and correct 
errors. During installation, the new system becomes a part of the daily activities of the 
organization. Implementation activities also include initial user support such as the 
finalization of documentation, training programs, and ongoing user assistance. 

The final phase of SDLC is called maintenance. In this phase, information 
system is systematically repaired and improved. When a system is operating in an 
organization, users sometimes find problems with how it works and often think of better 
ways to perform its functions. Also the organization’s needs with respect to the system 
change over time. In maintenance, you make the changes that users ask for and modify 
the system to reflect changing business conditions. 

Waterfall model is the oldest and the most widely used paradigm for information 
systems development. While it does have weaknesses, it is significantly better than a 
haphazard approach. This model is suitable for the projects in which user requirements 
are certain and precise. The problems that are sometimes encountered with the linear 
sequential model are: 

—» Changes can cause confusion as the project team proceeds. 

—» It is often difficult for the customer to state all requirements explicitly. The linear 
sequential model requires this and makes difficulty to respond to changing 
customer requirements. 
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—» A working version of the system will be available to customers late in the project 
time-span. A major blunder, if undetected until the working program is reviewed, 
can be disastrous. 

—> The linear nature of the classic life cycle leads to “blocking states” in which some 
project team members must wait for other members of the team to complete 
dependent tasks. 

—> User involvement is limited. 

Different Approaches to Improving Information 
Systems Development 

Several different approaches have been developed in the continuous effort to improve the 
systems analysis and design process. The two important approaches are prototyping and 
joint application development (JAD). 

Prototyping 

Prototyping is a form of rapid application development (RAD). Prototyping is a rapid, 
iterative, and incremental process of systems development in which requirements are 
converted to a working system that is continually revised through close work between the 
development team and the users. We can build a prototype with any computer language 
or development tool, but special prototyping tools have been developed to simply the 
process. A prototype can be developed with some fourth-generation language (4GL), 
with the query and screen and report design tools of a database management system, and 
with tools called computer-aided software engineering (CASE) tools. 



In prototyping, the analyst works with users to determine the initial or basic requirements 
for the system. The analyst then quickly builds a prototype. When the prototype is 
completed, the users work with it and tell the analyst what they like and do not like about 
it. The analyst uses this feedback to improve the prototype and takes the new version 
back to the users. This iterative process continues until the users are relatively satisfied 
with what they have seen. 
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Ideally, the prototype serves as a mechanism for identifying information system 
requirements. In this case, we throw away the prototype (also called throwaway 
prototype) after identifying requirements. The actual information system is developed 
with an eye toward quality and maintainability based on the requirements. 

♦ Advantages: 

—> Useful for projects in which user requirements are uncertain or imprecise. 

—> It encourages active user and management participation. 

—» Projects have higher visibility and support because of the extensive user 
involvement. 

—» Users and management see working, software based solutions more rapidly. 

—» Errors and omissions tend to be detected earlier in prototypes. 

—> Testing and training are natural by-products. 

—» It is more natural process. 

—> It is most popular for small to medium-size projects. 

♦ Disadvantages: 

—> It increases lifetime cost to operate, support and maintain the system. 

—» It can solve the wrong problems since problem analysis is abbreviated or ignored. 
—> The product may have less quality because of speed in development. 

Joint Application Development (JAD) 

It is used for collecting information system requirements and reviewing system designs. 
It is a structured process in which users, managers, and analysts work together for several 
days in a series of intensive structured meetings run by a JAD session leader to specify or 
review system requirements. Here, people work together to agree on system requirements 
and design details, time and organizational resources are better managed. Group members 
are more likely to develop a shared understanding of what the IS is supposed to do. 

Computer-aided Software Engineering (CASE) Tools 

Computer-aided systems engineering (CASE) tools are the software programs that help 
the development team do their jobs more efficiently and more effectively. These tools 
support the drawing and analysis of system models. Some CASE tools also provide 
prototyping and code generation capabilities. Some examples are: Oracle’s Designer 
2000, Rational’s Rose, Platinum’s Erwin, Popkin’s System Architect 2001, and Visible 
System’s Visible Analyst. 

At the center of any CASE tool’s architecture is a developer’s database called a CASE 
repository. CASE repository is a system developer’s database where developers can 
store system models, detailed description and specification, and other products of system 
development. It is also called dictionary or encyclopedia. 

Around the CASE repository is a collection of tools or facilities for creating system 
models and documentation. These facilities generally include: 

• Diagramming tools -These tools are used to draw system models. 

• Dictionary tools - These tools are used to record, delete, edit, and output detailed 
documentation and specification. 
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• Design tools - These tools are used to construct system components including system 
inputs and outputs. These are also called prototyping tools. 

• Documentation tools - These tools are used to assemble, organize, and report on 




system models, descriptions and specifications, and prototypes. 

• Quality management tools - These tools are used to analyze system models, 
descriptions and specifications, and prototypes for completeness, consistency, and 
conformance to accepted rules of methodologies. 

• Design and code generator tools - These tools automatically generate database 
designs and application programs or significant portions of those programs. 

Today’s CASE tools provide two distinct ways to develop system models - forward 
engineering and reverse engineering. Forward engineering requires the system analyst 
to draw system models, either from scratch or from templates. The resulting models are 
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subsequently transformed into program code. Reverse engineering, on the other hand, 
allows a CASE tool to read existing program code and transform that code into a 
representative system model that can be edited and refined by the systems analyst. CASE 
tools that allow for bi-directional, forward and reverse engineering are said to provide for 
“round-trip engineering”. The figure below shows CASE tool architecture. 
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Modeling Tools for Systems Analyst 

Entity Relationship Diagram (E-R Diagram) 

During analysis phase, a systems analyst uses entity relationship data model (E-R 
model) as a conceptual data model. A conceptual data model is a detailed model that 
captures the overall structure of organizational data while being independent of any 
database management system or other implementation consideration. And an E-R model 
is a detailed, logical representation of the data for an organization or for a business area. 
The E-R model is expressed in terms of entities in the business environment, the 
relationships or associations among those entities, and the attributes or properties of both 
the entities and their relationships. An E-R model is normally expressed as an entity 
relationship diagram (E-R diagram), which is a graphical representation of an E-R 
model. It has three basic concepts: entities, attributes, and relationships. 

Entities 

An entity is a person, place, object, event, or concept in the user environment about 
which the organization wishes to capture and store data. An entity type (sometimes 
called an entity class or entity set) is a collection of entities that share common 
properties or characteristics. An entity instance (or instance) is a single occurrence of an 
entity type. 

Each entity type in E-R diagram is given a name. When naming entity types, we 
should use the following guidelines: 

• An entity type name is a singular noun like CUSTOMER, STUDENT, or 
AUTOMOBILE. 

• An entity type name should be descriptive and specific to the organization like 
PURCHASE ORDER for orders placed with suppliers to distinguish it from 
CUSTOMER ORDER for orders placed by customers. 

• An entity type name should be concise like REGISTRATION for the event of a 
student registering for a class rather than STUDENT REGISTRATION FOR CLASS. 

• Event entity types should be named for the result of the event, not the activity or 
process of the event like the event of a project manager assigning an employee to 
work on a project results in an ASSIGNMENT. 

Each entity type in E-R diagram should be defined. When defining entity types, we 
should use the following guidelines: 

• An entity type definition should include a statement of what the unique 
characteristics) is (are) for each instance. 

• An entity type definition should make clear what entity instances are included and 
not included in the entity type. 

• An entity type definition often includes a description of when an instance of the entity 
type is created or deleted. 

• For some entity types the definition must specify when an instance might change into 
an instance of another entity type. For example, a bid for a construction company 
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becomes a contract once it is accepted. 

• For some entity types the definition must specify what history is to be kept about 
entity instances. 

An entity type in E-R diagram is drawn using rectangle. This shape represents all 
instances of the named entity. We place entity type name inside the rectangle. For 
example, the figure below shows STUDENT entity type. 


STUDENT 


Attributes 

Each entity type has a set of attributes associated with it. An attribute is a property or 
characteristic of an entity that is of interest to the organization. For example, STUDENT 
entity type may have Student_ID, Student_Name, Home_Address, Phone_Number, and 
Major as its attributes. Similarly, EMPLOYEE entity type may have Employee_ID, 
Employee_name, and Skill, Address as its attributes. 

Each attribute in E-R diagram is given a name. When naming attributes, we should use 
the following guidelines: 

• An attribute is a noun like Customer_ID, Age, or Skill. 

• An attribute name should be unique. No two attributes of the same entity type may 
have the same name, and it is desirable, for clarity purposes, that no two attributes 
across all entity types have the same name. 

• To make an attribute unique and clear, each attribute name should follow a standard 
form. For example, Student_GPA as opposed to GPA_of_Students. 

• Similar attributes of different entity types should use the similar but distinguishing 
names. For example, Student_Residence_City_Name for STUDENT entity type and 
Faculty_Residence_City_Name for FACULTY entity type. 

Each attribute in E-R diagram should be defined. When defining attributes, we should use 
the following guidelines: 

• An attribute definition states what the attribute is and possibly why it is important. 

• An attribute definition should make it clear what is included and what is not included 
in the attributes value. For example, Employee_Monthly_Salary_Amount is the 
amount paid each month exclusive of any benefits, bonuses, or special payments. 

• An attribute definition may contain any aliases or alternative names. 

• An attribute definition may state the source of values for the attribute to make the 
meaning clearer. 

• An attribute definition should indicate if a value for the attribute is required or 
optional (to maintain data integrity). 

• An attribute definition may indicate if a value for the attribute may change (to 
maintain data integrity). 

• An attribute definition may also indicate any relationships that an attribute has with 
other attributes. For example, Age is determined from for Date_of_Birth. 

An attribute in E-R diagram is drawn using an ellipse. We place attribute name inside the 
ellipse with a line connecting it to the associated entity type. For example, the figure 
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below shows Student_Name and Age attributes of STUDENT entity type. 



Every entity type must have an attribute or set of attributes that distinguishes one instance 
from other instances of the same type. A candidate key is an attribute or combination of 
attributes that uniquely identifies each instance of an entity type. For example, a 
candidate key for a STUDENT entity type might be Stident_ID. 

Some entity type may have more than one candidate key. In such a case, we must 
choose one of the candidate keys as the identifier. An identifier (or primary key) is a 
candidate key that has been selected to be used as the unique characteristic for an entity 
type. We can use the following selection rules to select identifiers: 

• Choose a candidate key that will not change its value over the life of each instance of 
the entity type. 

• Choose a candidate key that will never be null. 

• Avoid using intelligent keys. 

• Consider substituting single value surrogate keys for large composite keys. 

The name of the identifier is underlined on an E-R diagram. For example, the figure 
below shows Student_Id as an identifier for a STUDENT entity type. 



A multivalued attribute may take more than one value for each entity instance. For 
example Phone_Number attribute of STUDENT entity type. We use a double-lined 
ellipse to represent multivalued attribute. 



An attribute that has meaningful component parts is called composite attribute. For 
example, Student_Name attribute of STUDENT entity type has First_Name, 
Middle_Name, and Last_Nmae as its component parts. 
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An attribute whose value can be computed from related attribute values is called derived 
attribute. For example, value of Age attribute is computed from Date_of_Birth attribute. 
We use dashed ellipse to denote derived attribute. 



Relationships 

A relationship is an association between the instances of one or more entity types that is 
of interest to the organization. We use diamond to denote relationships. Relationships are 
labeled with verb phrases. For example, if a training department in a company is 
interested in tracking with training courses each of its employees has completed, this 
leads to a relationship (called Completes) between the EMPLOYEE and COURSE entity 
types as shown in the figure below. 



As indicated by arrows, the cardinality of this relationship is many-to-many since each 
employee may complete more than one course, and each course may be completed by 
more than one employee. 

The cardinality of a relationship is the number of instances of one entity type that 
can (or must) be associated with each instance of another entity type. The cardinality of a 
relationship can be in one of the following four forms: one-to-one, one-to-many, many-to- 
one, and many-to-many. 

• One-to-one: An instance in entity type A is associated with at most one instance in 
entity type B, and an instance in entity type B is associated with at most one instance 
in entity type A. For example, cardinality between DEPARTMENT and 
CHAIRPERSON. 



• One-to-many: An instance in entity type A is associated with any number (zero or 
more) of instances in entity type B, and an instance in entity type B, however, can be 
associated with at most one instance in entity type A. For example, cardinality 
between MOTHER and CHILD. 
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• Many-to-one: An instance in entity type A is associated with at most one instance in 
entity type B, and an instance in entity type B, however, can be associated with any 
number (zero or more) of instances in entity type A. For example, cardinality 
between CHILD and MOTHER. 



• Many-to-many: An instance in entity type A is associated with any number (zero or 
more) of instances in entity type B, and an instance in entity type B is associated with 
any number (zero or more) of instances in entity type A. For example, cardinality 
between STUDENT and COURSE. 



The degree of a relationship is the number of entity types that participate in the 
relationship. The three most common relationships in E-R models are unary (degree one), 
binary (degree two), and ternary (degree three). Higher degree relationships are also 
possible, but they are rarely encountered. 




Unary relationship 


1 1 

__ X 


Is 

PERSON married 

to 

EMPLOYEE Manages 


L_i 

One-to-one 

1_1 

One-to-many 


Binary relationship 

Ternary relationship 

EMPLOYEE 

,s - PARKING 

— assigned — PlaCE 

PART 


One-lo-one 

T _ 

PRODUCT 

LINE 

— Contains PRODUCT 

VENDOR - Ships ^WAREHOUSE 


One-to-maoy 

Quantity 

STUDENT 

^ Regisiefs^ COURSE 

for^dK_ 


Many-to-many 



Fig: Example relationships of different degrees 
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A unary relationship is a relationship between the instances of one entity type. It is also 
called a recursive relationship. A binary relationship is a relationship between 
instances of two entity types. This is the most common type of relationship encountered 
in data modeling. A ternary relationship is a simultaneous relationship among the 
instances of three entity types. 

We can also use the concept minimum and maximum cardinality when we draw E-R 
diagrams. The minimum cardinality of a relationship is the minimum number of 
instances of an entity type that may be associated with each instance of another entity 
type. The maximum cardinality of a relationship is the maximum number of instances 
of an entity type that may be associated with each instance of another entity type. For 
example, suppose a portion of banking database as shown in the figure below. Here, the 
minimum number of accounts for a customer is one and the maximum number of 
accounts is many (unspecified number greater than one). Similarly, the minimum number 
of customers associated with an account is one and the maximum number of customers is 
many. 



When the minimum cardinality of a relationship is zero, then we say that the entity type 
is an optional participation or partial participation in the relationship. When the 
minimum cardinality of a relationship is one, then we say that the entity type is a 
mandatory participation or total participation in the relationship. In the figure above, 
the entity type ACCOUNT is a mandatory participation in the relationship. Similarly, the 
entity type CUSTOMER is a mandatory participation. 


♦ 

♦ 


Mandatory 1 cardinality 

Mandatory many (M) cardinality (1,2,..., many) 
(n is a number for an upper limit, if one exists) 

Optional 0 or 1 cardinality 

Optional zero-many cardinality (0, 1, 2,..., many) 


Fig: Cardinality symbols 
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Each relationship in E-R diagram is given a name. When naming relationships, we should 
use the following guidelines: 

• A relationship name is verb phrase like Assigned_to, Supplies, or Teaches. This 
name represents action taken, not the result of the action, usually in the present tense. 

• A relationship name should avoid vague names, such as Has or Is_related_to. 

Each relationship in E-R diagram should be defined. When defining relationships, we 
should use the following guidelines: 

• A relationship definition should explain what action is being taken and possibly why 
it is important. 

• It may be important to give examples to clarify the action. 

• The definition should explain any optional participation. 

• A relationship definition should explain any restrictions on participation in the 
relationship. 

• A relationship definition should explain the extent of history that is kept in the 
relationship. 

• A relationship definition should explain the reason for any explicit maximum 
cardinality other than many. 

• A relationship definition should explain whether an entity instance involved in a 
relationship instance can transfer participation to another relationship instance. 

Other E-R Notations 

• Associative Entity: An entity type that associates the instances of one or more entity 
types and contains attributes that are peculiar to the relationship between those entity 
instances is called associative entity. Associative entity is also called a gerund. For 
example, the first figure below shows a relationship with an attribute and the second 
figure shows an associative entity. 



A B 

EMPLOYEE -H- -&< CERTIFICATE -H- COURSE 
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• Weak Entity Type: An entity type may not have sufficient attributes to form a 
primary key. Such an entity type is termed as a weak entity type. An entity type that 
has a primary key is termed as a strong entity type. For a weak entity type to be 
meaningful, it must be associated with another entity type, called the identifying or 
owner entity type, using one of the key attribute of owner entity type. The weak entity 
type is said to be existence dependent on the identifying entity type. The relationship 
associating the weak entity type with the identifying entity type is called the 
identifying relationship. The identifying relationship is many-to-one form the weak 
entity type to the identifying entity type, and the participation of the weak entity type 
in the relationship is total. Although a weak entity type does not have a primary key, 
we use discriminator (or partial key) as a set of attributes that allows the distinction to 
be made among all the entities in the weak entity type. 



Supertypes and Subtypes 

• Subtype: Subtype is a subgrouping of the entities in an entity type that is meaningful 
to the organization and that shares common attributes or relationships distinct from 
other subgroupings. For example, an entity type STUDENT to GRADUATE 
STUDENT and UNDERGRADUATE SUTDENT. 

• Supertype: Supertype is a generic entity type that has a relationship with one or more 
subtypes. For example PATIENT with OUTPATIENT and RESIDENTPATIENT. 

There are several important business rules for supertype/subtype relationships. 

• Total specialization rule: Specifies that each entity instance of the supertype must be 
a member of some subtype in the relationship. 

• Partial specialization rule: Specifies that an entity instance of the supertype does not 
have to belong to any subtype. May or may not be an instance of one of the subtypes. 

• Disjoint rule: Specifies that if an entity instance of the supertype is a member of one 
subtype, it cannot simultaneously be a member of any other subtype. 

• Overlap rule: Specifies that an entity instance can simultaneously be a member of 
two (or more) subtypes. 
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Address 

Mama Gender 



Rank Position Test_Scone Class_Standing 


Fig: Example of supertype/subtype hierarchy 

In the figure above, PERSON is supertype and EMPLOYEE, ALUMNUS, and 
STUDENT are subtypes. Similarly, EMPLOYEE is supertype for FACULTY and 
STAFF subtypes and STUDENT is supertype for GRADUATE STUDENT and 
UNDERGRADUATE STUDENT subtypes. 

Supertype is connected with a line to a circle, which in turn is connected by a line to 
the subtypes. The U-shaped symbol indicates that the subtype is a subset of the supertype. 
Total specialization is shown by a double line from the supertype to the circle and partial 
specialization is shown by a single line. Disjoint versus overlap is shown by a “d” or an 
“o” in the circle. 

Some Exercises 

1. Construct an ER diagram for a car-insurance company whose customers own one or 
more cars each. Each car has associated with it zero to any number of recorded 
accidents. 

2. Construct an ER diagram for a hospital with a set of patients and a set of doctors. 
Associate with each patient a log of the various tests and examinations conducted. 

3. Construct an ER diagram of the library system in your college. 

4. Construct an ER diagram to maintain data about students, instructors, semester, and 
courses in a college. 

5. Construct an ERD to record the marks that students get in different exams of different 
course offerings. 
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Data Flow Diagram (DFD) 

Process modeling involves graphically representing the functions or processes that 
capture, manipulate, store, and distribute data between a system and its environment and 
between components within a system. A common form of a process model is a data flow 
diagram (DFD). 

A data flow diagram (DFD) is a tool that depicts the flow of data through a system 
and the work or processing performed by that system. It is also called bubble chart, 
transformation graph, or process model. There are two different sets of data flow 
diagram symbols, but each set consists of four symbols that represent the same things: 
data flows, data stores, processes, and sources/sinks (or external entities). The figure 
below shows two different sets of symbols developed by DeMacro and Yourdon and 
Gane and Sarson. The set of symbols we will use here was deviced by Gane and Sarson. 


process 


data store 


source/sink 


M - data flow M - 

DeMarco and Yourdon Gane and Sarson 

symbols symbols 


According to Gane and Sarson, rounded rectangles represent process or work to be 
done, squares represent external agents, open-ended boxes represent data store 
(sometimes called files or databases ), and arrows represent data flows or inputs and 
outputs to and from the processes. 

Process is the work or actions performed on data so that they are transformed, 
stored or distributed. Data store is the data at rest (inside the system) that may take the 
form of many different physical representations. External entity (source/sink) is the origin 
and/or destination of data. Data flow represents data in motion, moving from one place in 
a system to another. 
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Developing DFDs 

The highest-level view of a system is called context diagram or context DFD. A context 
DFD is used to document the scope of the project of development. It is also called 

environmental model. 

A project’s scope defines what aspect of the business, an information system or 
application is supposed to support and how the system being modeled must interact with 
other systems and the business as a whole. Because the scope of any project is always 
subject to change, the context diagram is also subject to constant change. The context 
DFD contains one and only one process and it has no data storage. Sometimes this 
process is identified by the number “0”. The figure below shows the context diagram of 
library system. 



The next step is to draw a DFD with major processes that are represented by the single 
process in the context diagram. These major processes represent the major functions of 
the system. This diagram also includes data stores and called level-0 diagram (or level-0 
DFD). A level-0 diagram is a DFD that represents a system’s major processes, data 
flows, and data stores at a high level of detail. In this diagram, sources/sinks should be 
same as in the context diagram. Each process has a number that ends in .0. The figure 
below shows level-0 DFD. 
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Here, we started with a high-level context diagram. Upon thinking more about the 
system, we saw that the larger system consisted of four processes. This process is called 
functional decomposition. Functional decomposition is an iterative process of breaking 
the description or perspective of a system down into finer and finer detail. When we 
repeat the decomposition until we reached the point where no subprocesses can logically 
be broken down any further, we get the lowest level of DFD called primitive DFD. 

When we decompose level-0 DFD, we get level-1 DFD. In level-1 DFD, we label 
subprocesses of process 1.0 to 1.1, 1.2, and so on. Similarly, subprocesses of process 2.0 
to 2.1, 2.2, and so on. In general, a level-n diagram is a DFD that is generated from n 
nested decompositions from a level-0 diagram. 
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Structured Methodologies 

Introduction 

Structured methodologies (or structured systems analysis and design) have been used to 
document, analyze, and design information systems since the 1970s. Structured refers to 
the fact that the techniques are step by step, with each step building on the previous one. 
Structured methodologies are top-down, progressing from the highest, most abstract level 
to the lowest level of detail - from the general to the specific. 

Structured development methods are process-oriented, focusing primarily on 
modeling the processes, or actions that capture, store, manipulate, and distribute data as 
the data flow through a system. These methods separate data from processes. 

The primary tool for representing a system’s component processes and the flow of 
data between them is the data flow diagram (DFD). The data flow diagram offers a 
logical graphic model of information flow, partitioning a system into modules that show 
manageable levels of detail. It rigorously specifies the processes or transformations that 
occur within each module and the interfaces that exist between them. 

Another tool for structured analysis is a data dictionary, which contains 
information about individual pieces of data and data groupings within a system. The data 
dictionary defines the contents of data flows and data stores so that systems builders 
understand exactly what pieces of data they contain. Process specification is another tool 
that describes the transformation occurring within the lowest level of data flow diagrams. 
They express the logic for each process. We can express the logic using structured 
English, decision table, decision tree etc. 

In structured methodology, software design is modeled using hierarchical 
structure charts. The structure chart is a top-down chart, showing each level of design, 
its relationship to other levels, and its place in the overall design structure. The design 
first considers the main function of a program or system, then breaks this function into 
subfunctions, and decomposes each subfunction until the lowest level of detail has been 
reached. A structure chart may document one program, one system (a set of programs) or 
part of one program. 

The Need for Structured Methodology 

Most information systems development organizations use structured methodology 
because it offers the following advantages: 

• Improve project management & control 

• Make more effective use of experienced and inexperienced development staff 

• Develop better quality systems with low cost 

• Make projects resilient to the loss of staff 

• Enable projects to be supported by computer-based tools such as computer-aided 
software engineering (CASE) systems 

• Establish a framework for good communications between participants in a project 
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• Enable projects to deliver the product on time because it allows to plan, manage 
and control a project well 

• Respond to the changes in the business environment while project progresses 

• Improves the overall productivity by encouraging on-time delivery, meeting 
business requirements, ensuring better quality, and using human resources 
effectively. 


Role of CASE in Data Modeling 


Data models are stored in a repository. CASE (computer-aided systems engineering) 
provides the repository for storing the data models and its detail description. Most CASE 
tools support computer-assisted data modeling and database design. CASE supports in 
drawing and maintaining the data models and their underlying details. 

Using CASE product, you can easily create professional, readable data models 
without the use of paper, pencil, erasers, and templates. The models can be easily 
modified to reflect corrections and changes suggested by end users - you don’t have to 
start over. Also, most CASE products provide powerful analytical tools that can check 
your models for mathematical errors, completeness, and consistency. Some CASE 
products can even help you analyze the data models for consistency, completeness, and 
flexibility. 

Also, some CASE tools support reverse engineering of existing files and database 
structures into data models. The resulting data models represent physical data models that 
can be revised and reengineered into a new file or database, or they may be translated 
into their equivalent logical models. The logical data models could then be edited and 
forward engineered into a revised physical data model and subsequently a file or database 
implementations. 
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Systems Analysis 

Systems Planning and Initial Investigation 

The primary purpose of systems planning is to identify problem’s nature and its scope. It 
also includes preliminary (or initial) investigation and feasibility study. Initial 
investigation is used to understand the problem, define the project scope and constraints, 
identify the benefits, estimate the time and costs, and interact with managers and users. 
Feasibility study is used to determine some feasibility (economic, operational, technical 
feasibility etc) of the system. 

The purpose of this phase is twofold. First, it answers the question, “Is this project 
worth looking at?” Second, assuming that the problem is worth looking at, it establishes 
the size and boundaries of the project, the project vision, any constraints or limitations, 
the required project participants, and the budget and schedule. 

Information Gathering Techniques 

To develop an information system, we first must be able to correctly identify, analyze, 
and understand what the users’ requirements are or what the user wants the system to do. 
To know users’ requirements, we use information gathering techniques. Information 
gathering techniques are also called requirements discovery techniques or fact finding 
techniques or data collection techniques. Information gathering includes those 
techniques to be used by system analysts to identify or extract system problems and 
solution requirements from the user community. Systems analysts need an organized 
method for information gathering. Some information gathering techniques are discussed 
below: 

Sampling of Existing Documentation, Forms, and Files 

When we are studying an existing system, we can develop a good feel for the system by 
studying existing documentation, forms, and files. A good analyst always gets facts from 
the existing documentation rather than from people. 

Because it would be impractical to study every occurrence of every form or record in 
a file or database, system analysts normally use sampling techniques to determine what 
can happen in the system. 

Sampling is the process of collecting a representative sample of documents, forms, 
and records. The most commonly used sampling techniques are randomization and 
stratification. 

Randomization is a sampling technique in which there is no predetermined pattern or 
plan for selecting sample data. 

Stratification is a systematic sampling technique that attempts to reduce the variance 
of the estimates by spreading out the sampling. 

Research and Site Visits 

In this technique, we perform site visits at systems they know have experienced similar 
problems. If these systems are willing to share, valuable information can be obtained that 
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may save tremendous time and cost in the development process. 

Computer trade journals and reference books are also a good source of information. 
They can provide us with information how others have solved similar problems. Also, 
through the Internet we can collect immeasurable amounts of information. 

Observation of the Work Environment 

Observation is an effective data-collection technique for obtaining an understanding of a 
system. In this technique, the systems analyst either participates in or watches a person 
performing activities to learn about the system. 

Advantages : 

—» Data gathered can be highly reliable. Sometimes observations can be conducted to 
check the validity of data obtained directly from individuals. 

—» The systems analyst is able to see exactly what is being done. 

—> It is relatively inexpensive compared to other fact-finding techniques, because 
other techniques usually require more employees. 

—» It allows the system analyst to do work measurement. 

Disadvantages : 

—» People usually feel uncomfortable when being watched to their work. 

—> Some system activities may take place at odd times, causing a scheduling 
inconvenience for the system analyst. 

—» It may cause interruption. 

—» Some tasks may not always be performed by observation. 

Questionnaires 

This technique is used to conduct surveys through questionnaires. Questionnaires are 
special purpose documents that allow the analyst to collect information and opinions 
from the respondents. The document can be mass-produced and distributed to 
respondents, who can then complete the questionnaire on their own time. Questionnaires 
allow the analyst to collect facts from a large number of people. 

Types of Questionnaires 

There are two formats of questionnaire, free-format and fixed-format. Free-format 
questionnaire offer the respondent to record the answer in the space provided after the 
questionnaire. 

Fixed-format questionnaire contain questions that require selection of predefined 
responses. In this format, the respondent must choose from the available answer. 
There are three types of fixed-format questions: 

—» Multiple Choice Questions: - The respondent is given several answers of a 
question. The respondent should be told if more than one answer can be selected. 

—» Rating Questions: - The respondent is given a statement and asked to use 
supplied responses to state an opinion. 

—» Ranking questions: - The respondent is given several possible answers, which 
are to be ranked in the order of preference or experience. 

Advantages 

—» Most questionnaires can be answered quickly. 

—» Inexpensive for gathering data from a large number of individuals. 
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—> Responses can be tabulated and analyzed quickly. 

Disadvantages 

—» There is no guarantee that an individual will answer or expand on all the 
questions. 

—» Questionnaires tend to be inflexible. 

—> It not possible for the systems analyst to observe and analyze the respondent’s 
body language. 

—> There is no immediate opportunity to clarify a vague or incomplete answer to 
questions. 

—» Good questionnaires are difficult to prepare. 

—> The number of respondents is often low. 

Interviews 

The personal interview is generally recognized as the most often used fact-finding 
technique. Interviews are the fact-finding techniques whereby the systems analysts 
collect information from individuals through face-to-face interaction. 

There are two roles assumed in an interview. The systems analyst is the interviewer, 
responsible for organizing and conducting the interview. The system user or system 
owner is the interviewee, who is asked to respond to a series of questions. 

Types of Interviews 

There are two types of interviews: unstructured and structured. Unstructured 
interviews are conducted with only a general goal or subject in mind and with few, if 
any, specific questions. Structured interviews on the other hand are conducted with a 
set of specific questions to ask the interviewee. 

Types of Questions 

There are two types of questions in interview: open-ended and closed-ended. Open- 
ended questions allow the interviewee to respond in any way that seems appropriate. 
But, closed-ended questions restrict answers to either specific choices or short, direct 
responses. 

Advantages 

—» Interviews give the analyst an opportunity to motivate the interviewee to respond 
freely and openly to questions. 

—» Interviews allow more feedback from the interviewee. 

—» Interviews give the analyst an opportunity to observe the interviewee’s nonverbal 
communication. 

Disadvantages 

—» Interviewing is a very time-consuming and therefore costly fact-finding approach. 
—» Success of interviews is highly dependent on the systems analyst’s human 
relational skills. 

—» Interviewing may be impractical due to the location of interviewees. 

Discovery Prototyping 

Discovery prototyping is the act of building a small-scale, representative or working 
model of the users’ requirements to discover or verify the requirements. 

Usually only the areas where the requirements are not clearly understood are 
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prototyped. Creating discovery prototypes enables the developers as well as the users to 
better understand and refine the requirements involved with developing the system. 

Advantages 

—» Allows users and developers to experiment with the software and develop an 
understanding of how the system might work. 

—» Aids in determining the feasibility and usefulness of the system before high 
development costs are incurred. 

—> Serves as a training mechanism for users. 

—» Aids in building system test plans and scenarios to be used last in the system 
testing process. 

—» May minimize the time spent for fact-finding and help to define more stable and 
reliable requirements. 

Disadvantages 

—> Users and developers may need to be trained in the prototyping approach. 

—» Doing prototyping may extend the development schedule and increase the 
development costs 

—» Users may develop unrealistic expectations. 

Joint Requirements Planning (JRP) 

It is a process whereby highly structured group meeting is conducted to analyze problems 
and define requirements. JRP is a subset of a more comprehensive joint application 
development (JAD). The JRP participants are: 

—» Sponsor: - This person is normally an individual who is in top management and 
has authority that spans the different departments and users who are to be 
involved in the systems project. 

—» Facilitator: - The JRP facilitator or leader is usually responsible for leading all 
sessions that are held for a systems project. 

—» Users and Managers: - Users devote themselves to the JRP sessions to 
effectively communicate business rules and requirements, review design 
prototypes and make acceptance decisions. Managers approve project objectives, 
establish project priorities, approve schedules and costs, and approve identified 
training needs and implementation plans. 

—» Scribe(s): - Scribes are responsible for keeping records pertaining to everything 
discussed in the meeting. 

—» IT Staff: - IT personnel listen and take notes regarding issues and requirements 
voiced by the users and managers. Normally, IT personnel do not speak unless 
invited to do so. 

Benefits 

—» It actively involves users and managers in the development project. 

—» It reduces the amount of time required to develop systems. 

—» When JRP incorporates prototyping as a means for conforming requirements and 
obtaining design approvals, the benefits of prototyping are realized. 

Structured Analysis Tools 


Downloaded from: http://www.bsccsit.com 






Systems Analysis & Design 


Page 5 


Chapter 4 


Structured analysis includes different tools like DFD (data flow diagram), ERD (entity 
relationship diagram), data dictionary, structured English, decision table, and decision 
tree. 


Feasibility Study 

Feasibility is the measure of how beneficial or practical the development of information 
system will be to an organization. Feasibility study is the process by which feasibility is 
measured. Feasibility analysis is appropriate to the systems analysis phase. 

Four Tests for Feasibility 

During systems analysis phase, the system analyst identifies different alternate solutions and 
analyzes those solutions for feasibility. To analyze different alternative solutions, most 
analysts use four categories of feasibility tests: operational feasibility, technical 
feasibility, schedule feasibility, and economic feasibility. 

1. Operational Feasibility: It is a measure of how well the solution will work in an 
organization. It is also a measure of how people feel about the system/project. So, 
this feasibility is people oriented. Operational feasibility addresses two major 
issues: 

a. Is the problem worth solving, or will the solution to the problem work? 

b. How do end users and management feel about the problem (solution)? 
When determining operational feasibility, usability analysis is often performed 
with a working prototype of the proposed system. Usability analysis is a test of 
system’s user interfaces and is measured in how easy they are to learn and to use 
and how they support the desired productivity levels of the users. Usability is 
measured in terms of ease of learning, ease of use, and satisfaction. 

2. Technical Feasibility: It is a measure of practically of a specific technical 
solution and availability of technical resources and expertise. Technical feasibility 
is computer oriented. This feasibility addresses three major issues: 

a. Is the proposed technology or solution practical? 

b. Do we currently possess the necessary technology? 

c. Do we possess the necessary technical expertise, and is the schedule 
reasonable? 

3. Schedule Feasibility: It is a measure of how reasonable the project timetable is. 
Schedule feasibility is the determination of whether the time allocated for a 
project seems accurate. Projects are initiated with specific deadlines. It is 
necessary to determine whether the deadlines are mandatory or desirable. If the 
deadlines are desirable rather than mandatory, the analyst can propose alternative 
schedules. 

4. Economic Feasibility: It is the measure of the cost-effectiveness of a project or 
solution. This feasibility deals with costs and benefits of the information system. 
The bottom-line in many projects is economic feasibility. During the early phases 
of the project, economic feasibility analysis amounts to little more than judging 
whether the possible benefits of solving the problem are worthwhile. However, as 
soon as specific requirements and alternative solutions have been identified, the 
analyst can determine the costs and benefits of each alternative. 
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Some other feasibility tests are also possible. These are legal and contractual feasibility 
and political feasibility. Legal and contractual feasibility is the process of assessing 
potential legal and contractual ramifications due to the construction of a system. Political 
feasibility is the process of evaluating how key stakeholders within the organization view 
the proposed system. 

Cost-Benefit Analysis Techniques 

Economic feasibility has been defined as a cost-benefit analysis. Most schools offer 
coerces like financial management, financial decision analysis, and engineering 
economics and analysis for cost benefit analysis. The cost benefit analysis techniques 
include: 

• How much will the system costs? 

• What benefits will the system provide? 

• Is the proposed system cost-effective? 

How much will the system costs? 

Costs fall into two categories: costs associated with developing the system and costs 
associated with operating the system. The former costs can be estimated from the start of 
the project and should be refined at the end of each phase of the project. The later can be 
estimated only after specific computer-based solution has been defined. 

System development costs are usually onetime costs that will not recur after the 
project has been completed. Many organizations have standard cost categories that must 
be evaluated. In the absence of such categories, we use the following list: 

• Personnel cost - The salaries of systems analysts, programmers, consultants, data 
entry personnel, computer operators, secretaries, and the like who work on the 
project. 

• Computer usage - The cost in the use of computer resources. 

• Training - Expenses for the training of computer personnel or end-users. 

• Supply, duplication, and equipment costs. 

• Cost of any new computer equipment and software. 

The operating costs tend to recur throughout the lifetime of the system. The costs in this 
case can be classified as fixed or variable. 

• Fixed costs - Fixed costs occur at regular intervals but at relatively fixed rates. 
Some examples include: lease payments and software license payments, salaries 
of IS operators and support personnel etc. 

• Variable costs - Variable costs occur in proportion to some usage factor. Some 
examples include: costs of computer usage (e.g., CPU time used, storage used), 
supplies (e.g., printer paper, floppy disks), overhead costs (e.g., utilities, 
maintenance, and telephone service) etc. 

What benefits will the system provide? 

Benefits normally increase profits or decrease costs. Benefits can be classified into two 
categories: tangible and intangible. 
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• Tangible benefits - Tangible benefits are those that can be easily quantified. 
These benefits are usually measured in term s of monthly or annual savings or of 
profit to the firm. Alternatively, these benefits might be measured in terms of unit 
cost savings or profit. Some examples of tangible benefits are: fewer processing 
errors, increased throughput, decreased response time, elimination of job steps, 
increased sales, reduced credit losses, and reduce expenses. 

• Intangible benefits - Intangible benefits are believed to be difficult or impossible 
to quantify. Unless these benefits are at least identified, it is entirely possible that 
many projects would not be feasible. Some examples of intangible benefits are: 
improved customer goodwill, improved employee morale, better service to 
community, and better decision making. 

Unfortunately, if a benefit cannot be quantified, it is difficult to accept the validity of an 
associated cost-benefit analysis that is based on incomplete data. 

Is the proposed system cost-effective? 

There are three popular techniques to assess economic feasibility, also called cost- 
effectiveness: payback analysis , return to investment, and net present value. 

One concept that is shared by all three techniques is the time value of money - a 
dollar today is worth more than a dollar one-year from now. 

Some of the costs of the system will be accrued in after implementation. Before cost- 
benefit analysis, these costs should be brought back to the current dollars. Present value 
is the current value of a dollar at any time in the future. It is calculated using the formula: 

PV n = 1/(1 + if 

Where PV n is the present value of $1.00 n years from now and i is the discount rate. 

• Payback analysis - It is a technique for determining if and when an investment 
will pay for itself. Because system development costs are incurred long before 
benefits begin to occur, it will take some time for the benefits to overtake the 
costs. After implementation, there will be additional operating expenses that must 
be recovered. Payback analysis determines how much time will lapse before 
accrued benefits overtake accrued and continuing costs. This period of time is 
called payback period, that is, the period of time that will lapse before accrued 
benefits overtake accrued costs. 

• Retum-on-investment analysis - This technique compares the lifetime 
profitability of the solution. It is a percentage rate that measures the relationship 
between the amounts the business gets back from an investment and the amount 
invested. It is calculated as follows: 

Lifetime ROl = (Estimated lifetime benefits - Estimated lifetime costs)/Estimated 

lifetime costs 

• Net present value - It is an analysis technique that compares costs and benefits 
for each year of the system’s lifetime. Many managers consider it the preferred 
cost-benefit analysis technique. 
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